Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core Lib Documentation: storage_node module #7043

Merged
merged 6 commits into from
Jan 11, 2025

Conversation

TAdev0
Copy link
Contributor

@TAdev0 TAdev0 commented Jan 10, 2025

No description provided.

@reviewable-StarkWare
Copy link

This change is Reviewable

Copy link
Collaborator

@orizi orizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed all commit messages.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @TAdev0)


corelib/src/starknet/storage/storage_node.cairo line 14 at r1 (raw file):

//! Storage nodes are particularly valuable when defining structs containing phantom types like
//! `Map` and `Vec`. When a struct is marked with `#[starknet::storage_node]`, it automatically
//! becomes a phantom type, regardless of whether it was explicitly annotated as such.

hmm - it just is marking it as phantom - the "regardless" part seems confusing for me.

Code quote:

//! Storage nodes are particularly valuable when defining structs containing phantom types like
//! `Map` and `Vec`. When a struct is marked with `#[starknet::storage_node]`, it automatically
//! becomes a phantom type, regardless of whether it was explicitly annotated as such.

Copy link
Contributor Author

@TAdev0 TAdev0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @orizi)


corelib/src/starknet/storage/storage_node.cairo line 14 at r1 (raw file):

Previously, orizi wrote…

hmm - it just is marking it as phantom - the "regardless" part seems confusing for me.

removed this part

Copy link
Collaborator

@orizi orizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed all commit messages.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @TAdev0)


corelib/src/starknet/storage/storage_node.cairo line 20 at r2 (raw file):

//! more appropriate to make them storable using `#[derive(Store)]`. This alternative approach
//! still enables access to individual struct members through `SubPointers` without imposing the
//! phantom type behavior.

you should probably mention the different storage layout for the diffrent cases.

Store:
continuously in the same variable space (up to the size 256 felts)

starknet_node:
Each member is an addition to the key to the location of the storage var.

Code quote:

//! While you can declare any struct as a storage node (even those without phantom types), doing so
//! will make that struct a phantom type. For structs that don't contain phantom types, it's often
//! more appropriate to make them storable using `#[derive(Store)]`. This alternative approach
//! still enables access to individual struct members through `SubPointers` without imposing the
//! phantom type behavior.

Copy link
Contributor Author

@TAdev0 TAdev0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @orizi)


corelib/src/starknet/storage/storage_node.cairo line 20 at r2 (raw file):

Previously, orizi wrote…

you should probably mention the different storage layout for the diffrent cases.

Store:
continuously in the same variable space (up to the size 256 felts)

starknet_node:
Each member is an addition to the key to the location of the storage var.

just added storage layout precisions

Copy link
Collaborator

@orizi orizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @TAdev0)

@orizi orizi enabled auto-merge January 11, 2025 17:47
@orizi orizi added this pull request to the merge queue Jan 11, 2025
Merged via the queue into starkware-libs:main with commit a2dd9e0 Jan 11, 2025
47 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants